HPAVC

home *** CD-ROM | disk | FTP | other *** search

/ HPAVC / HPAVC CD-ROM.iso / pc / DETAILS.ZIP / details.txt

Wrap

Text File | 1997-02-28 | 28.7 KB | 559 lines

Some technical details about Videocrypt --------------------------------------- Markus Kuhn -- 1994-08-02 In this file, I'll collect some of the details known or assumed about the Videocrypt pay-TV access control system. Consider it as some kind of frequently asked questions list with answers about the system. 1 Basic principle Videocrypt encodes the TV image by cutting each line of the image in two pieces at some cut point and then exchanges these two line fragments in the broadcasted pictures. E.g. if a line like 0123456789 passes the encoder, the output might look like 4567890123 where the digits represent the pixels of the image. There are 256 possible cut points and there are no cut points directly near the image border (the miniumum distance from the margin is about 12-15% of the image width) which is the reason why you sometimes still can see vertical patterns even on an encrypted image. The sound is currently not encrypted. Several times per second, a computer at the broadcasting station generates a 32 byte long message which is broadcasted encoded together with forward error correction information in the first invisible lines of the TV signal similar to teletext. About every 2.5 seconds, one of these 32-byte messages is processed in the encoder by a secret hash algorithm which transforms the 32-byte message into a 60-bit value. These 60 bits are then used by a second algorithm in order to determine the 8-bit cut point coordinates for each line for the next 2.5 seconds. No details about this second algorithm are known, but think of it just as some kind of 60-bit pseudo random number generator (PRNG) were the 60-bit output from the secret hash function is used as a start value (seed). The decoder receives the 32-byte messages and other data together with the TV signal, applies some error correction algorithms and passes all 32-byte packets to the smart card in the decoder's card slot. The smart card implements the same secret hash function and answers with the same 60-bit value as the one which is used in the encoder. By using this 60-bit answer from the card, the decoder hardware can generate with the same PRNG the same cut point sequence as the encoder and can so reconstruct the original image by again exchanging the two line fragments. The secret hash function is a cryptographically strong system which is designed so that it is extremely difficult to guess the algorithm of this function by looking at many pairs of 32-byte/60-bit values. Apart from being the source for the generation of the 60-bit PRNG seed, the 32-byte messages from the broadcasting station contain card numbers so that individual cards can be addressed and they contain commands like activation, deactivation and pay-per-view account modification. In addition, the 32-byte packets contain a digital signature (currently 4 bytes) that allows the card to test whether the 32-byte messages really originate from the encoder and have not been generated by someone analysing the card. Again, this digital signature like the hash function has been designed so that it is difficult to find out how to generate a correct signature by looking at enough examples. This prevents choosen-text attacks, where someone tries to probe the secret hash function with very carefully selected 32-byte messages and this prevents hackers to generate new activation commands for the card. In early 1993, someone managed to get access to the secret hash functions of several stations which use Videocrypt (e.g., British Sky Broadcasting, Adult Channel, JSTV, BOB, Red Hot TV). Most of these systems used the same hash and signature algorithm and the only difference between the stations was a 32-byte secret key table. It is not known, how it was possible to get this information. Either someone from the company who manufactured the cards (News Datacom Ltd.) released this information or it was possible for someone to read out the EEPROM contents of the card processor (very difficult, but theoretically possible). With this knowledge it was then quite easily possible for the original hackers to produce 'clone cards'. These are simple PCBs with a cheap microcontroller (e.g. one of Microchip's PIC family), which implements only the secret hash function and serial I/O procedures in its EPROM and answers with the correct 60-bit values to 32-byte messages just as the real cards do. For several channels, clone cards are still available, but BSkyB distributed new 09 series cards in spring 1994 and switched on 1994-05-18 to a new secret hash ans signature function. Consequently, all clone cards stopped to work. The clone cards didn't implement any interpretation procedures for card activation, deactivation and pay-per-view functions, so their software is considerably simpler than the one in the real cards. This resulted in some tiny differences between the reaction of the clone card software and the reaction of the original card software on pathological 32-byte messages. These differences were used in counter measures (commonly referred to as ECMs) against clone cards several times in 1993 and 1994 by BSkyS and News Datacom in order to deactivate clone cards, but it was quite easy each time to find out these tiny bugs in the clone card software and correct it. There are two microprocessors in a typical Videocrypt decoder. An Intel 8052 microcontroler manages the communication between the smart card and the rest of the system. As the software of this processor is not read protected, it was also possible to reprogram this chip (by using the EPROM version 8752BH) so that the hash algorithm is performed inside the decoder. Then no external card is needed at all for the channels for which the hash algorithm was implemented in the 8752. The second processor is a Motorola 6805 variant and its internal ROM contents can't be read out easily. The Motorola decodes the data that comes with the TV signal, applies error correction algorithms to this data, exchanges the 32-byte messages and 8-byte answers with the Intel processor and controls the PRNG and the on-screen display hardware. There are also Videocrypt II decoders available. These work almost like the Videocrypt decoders and the only important difference is a new software in the Intel and Motorola processor. Videocrypt II decoders get their data from other invisible TV lines than Videocrypt, and it is possible to broadcast a signal encrypted in a way that allows both Videocrypt and Videocrypt II to decode it with different smart cards. More detailed basic information about Videocrypt has been published in the European patent EP 0 428 252 A2 ("A system for controlling access to broadcast transmissions"). You can order a copy for little money (about 10 DM) from the European Patent Office (Schottenweldgasse 29, A-1072 Wien, Austria) if you are interested. 2 Security of the Videocrypt system The system is very secure, because all secret parts that are essential to a successful decryption are located in the smart card and if the card's secret hash algorithm/key becomes known, it can easily be replaced by just sending new cards to the subscribers. This card exchange can also be used if details about the format of the commands hidden in the 32-byte sequences sent to the card become known which allows together with the knowledge of the signature algorithm to generate new activation messages and to filter out deactivation messages. There are however at least two obvious security flaws of the system which can't be removed by new smart card generations: - The dialog between the card and the decoder is the same synchronously for all Videocrypt decoders switched to this channel. I.e., the decoder doesn't add any card specific or decoder specific information to the traffic. This makes it possible to use one card for several decoders. E.g. it is possible to record the 32-byte messages broadcasted by the station during an evening with a PC, then send these messages to someone else with an original card who asks his card for the 60-bit answers to all the recorded messages. If this person then sends these 60-bit answers back, then you can use this data in order to descramble the VCR recorded program of this evening (delayed data transfer). However, decoding VHS recorded encrypted signals produces minor color distortions and a few VCRs don't preserve the Videocrypt data stream in the first invisible lines that accompanies the TV signal. It is also possible to distribute the 60-bit answers from one card in real-time with cables to many decoders in a house or with radio signals to many decoders in a larger region. - The simple cut-and-exchange encryption method and the fact that two consecutive lines in an image are almost always nearly identical makes it possible to try all 256 possible cut points and to select the one which causes both lines to fit together best. This method has alreday been implemented on fast PC's with framegrabbers which load the image into the memory and display it corrected on the computer screen (many seconds per frame), on parallel supercomputers which allow almost real-time decryption and with special hardware that achieves real-time decryption. Howevery, with this decoding method, there are severe image quality losses and many additional problems which together with the high hardware costs required (much higher than a regular subscription) don't make this approach very practical for every day usage. Both these security gaps in the videocrypt systems don't allow comfortable and easy high quality decryption like using a card, but the described methods have already been successfully used by a few technically skilled peoples for watching encrypted program. 3 ISO card protocol The card and the protocol used to cummunicate with it conform exactly to the international standard ISO 7816. The options used from this standard are: T=0 asynchronous halfduplex character transmission protocol, active low reset and inverse convention. Only a few basic principles of the ISO protocol will be explained here. For much more detailed information, please read the ISO standard which you can order from your national standards body (e.g. DIN, ANSI, AFNOR, BSI, DS, etc.). There are three parts of the standard: ISO 7816-1 describes physical characteristics of the card and quality tests a card has to survive, ISO 7816-2 describes the location and meaning of the contacts and ISO 7816-3 (most important) describes the electrical characteristics, the answer-to-reset message and the protocol. The data format is an asynchronous 9600 bit/s serial format similar to that used on RS-232 lines with 8 data bits, 1 parity bit and two stop bits. The parity is even (but if inverse bit meaning convention is used, a RS-232 interface has to be programmed for odd parity in order to produce the correct bit). There is also an error detection and character repetition mechanism in the protocol which is not supported by RS-232 interfaces: If the receiving device (card or decoder) detects a parity error, it sends an impulse during the stop bit time. This will tell the sender to retransmit one byte. After a reset impulse to the card, the card answers with an answer-to-reset message with some information about the requirements of the card. If the first byte is 3fh, then this means that in order to read the bytes with a RS-232 interface, you'll have to invert and reverse all bits. A typical answer-to-reset looks e.g. like the following one: 3f fa 11 25 05 00 01 b0 02 00 00 4d 59 00 81 80 | | | | | | 'historic characters' with| | | | | | | information about chip and| | | | | | | software version, etc. | | | | | | | | | | +- low nibble: protocol type T=0, | | | | high nibble: end of ISO part | | | | | | | +- requests 5 additional stop bits | | | | | +- encodes programming voltage and max. programming | | current (here: 5V, 50mA) | | | +- clock freq.: 11h=3.5 MHz, 31h=7 MHz | +- the 0ah low nibble means: 10 'historic characters' which are not defined in the ISO standard are appended to the reset answer The answer-to-reset message has a variable length format. Some bits specify whether certain bytes are present or not. If the lowest bit in the high nibble of the second byte is 1, then the above shown third byte is present and determines the relation between the bit rate and the clock frequency after the reset answer. E.g., 11h means that 372 clock cycles are one bit duration (default), i.e. with a clock frequency of 3.5712 Mhz, the bit frequency is 9600 Hz. In the Videocrypt system, the bit rate is always 9600 bits/s, but a value of 31h (= factor 744) in the third byte requests a doubled clock frequency (~7MHz) from the decoder. Other values are not supported by the Videocrypt decoder. The Videocrypt decoder supports several programming voltages (5 V, 12.5 V, 15 V and 21 V, max. 50 mA current) and different numbers of stop bits (>= 5) sent to the card. All these parameters can be selected in the answer-to-reset. Of the 'historic characters' part, the decoder only verifies that it is at least 7 characters long and that the values 4dh und 59h are at the positions as in the example, otherwise the card is rejected. No more details about the information in the historic characters part of a Videocrypt card is currently known. For the detailed format of the answer-to-reset message, please consult ISO 7816-3. The T=0 protocol is a half duplex master slave protocol. The decoder can send commands to the card followed by a data transmission either to or from the card. The card can do some limited flow control and can request or deactivate the programming voltage VPP selected in the answer-to-reset using "procedure bytes". If the decoder initiates a command, it sends five header bytes to the card, e.g. 53 78 00 00 08 The first byte (CLA) is the command class code and is always 53h in the Videocrypt system. The second byte (INS) is the instruction code. Its lowest bit is always 0 and instruction codes have never a 6 or 9 high nibble (you'll see below, why). The following 2 bytes (P1 and P2) are a reference (e.g. an address) completing the instruction code and a Videocrypt decoder sets them always to 00 00. The final byte (P3) codes the number of data bytes which are to be transmitted during the command. P3=0 has a special meaning: In data transfers from the card, it indicates 256 data bytes, in data transfers from the decoder, it indicates 0 bytes. The direction of the data transfer is determined by CLA and INS and must be known in advance by both the card and the decoder. After transmission of such a 5-byte header, the decoder waits for a 'procedure byte' from the card. The following procedure bytes are possible: 60h Please wait, I'll send another procedure byte soon, don't timeout. INS Now let's transfer all (remaining) data bytes, I don't need programming voltage. INS+1 Now let's transfer all (remaining) data bytes and please activate VPP. INS xor ffh Now let's transfer another single data byte, I don't need programming voltage. (INS+1) xor ffh Now let's transfer another single data byte, and please activate VPP. 6Xh or 9Xh This byte SW1 indicates an end of the data transfer and requests to deactivate VPP. A second status byte SW2 follows from the card. SW1 SW2 = 90 00 indicates a normal termination, other values report e.g. an error. After each data transfer, the decoder waits for another procedure byte. E.g., a typical decoder<->card dialog looks like this (command 78h requests the 60-bit answer as 8 bytes from the card): decoder sends header 53 78 00 00 08 card sends procedure byte (all at once, no VPP) 78 card sends P3 data bytes 80 52 02 79 f5 39 7c 0e card closes with SW1 and SW2 90 00 4 Videocrypt protocol The newer Videocrypt smart cards don't require any programming voltage (the VPP pin isn't even connected). Although, the ISO standard requires only 2 stop bits after each transfered byte, Videocrypt decoders seem to require more than 5 stop bits. As PC serial ports don't support more than 2 stop bits directly, a card emulator software has to wait for about 0.5-1.5 ms after each byte. Cards can announce in the answer-to-reset message, how many stop bits they require and Videocrypt cards also do require more than 2 stop bits. A videocrypt decoder knows the following 10 commands (all with CLA=53h and P1=P2=00h): INS length (P3) direction purpose --------------------------------------------------------------------- 70h 6 from card serial number, etc. 72h 16 to card message from previous card 74h 32 to card message from station 76h 1 to card authorize button pressed 78h 8 from card 60-bit answer 7ah 25 from card onscreen message 7ch 16 from card message to next card 7eh 64 from card ??? \ 80h 1 to card ??? > perhaps Fiat-Shamir 82h 64 from card ??? / authentication? The following things are known about the data bytes of these commands: 70h: In BSkyB cards, the 70h data contains the card issue number (e.g. 07 or 09) in the low nibble of the first byte. The high nibble of the first byte seems to be always 2. The next 4 bytes form an 32-bit bigendian integer value which corresponds to the decimal card number without the final digit of the card number (which is perhaps a check digit, algorithm unknown). The meaning of the final byte is unknown. 72h and 7ch: Several times per second, the decoder requests with 7ch 16 bytes from the card. If a card is removed and a new card is inserted in the decoder without switching off the power of the decoder, then shortly after the card reset, the decoder sends the latest 7ch data bytes from the previous card in a 72h message to the new card. In this way, 16 bytes information (e.g. the status of a pay-per-view account or a list of activated channels?) can be transfered from one card to the next. 74h and 78h: The 74h command transfers the 32-byte messages from the broadcasting station to the card. If the third bit (value 8) in the first byte is set, then the decoder will ask with a 78h command for the 60-bit answer. This happens about every 5th 74h packet every 2.5 seconds. The high nibble of the final byte in the 78h data is ignored by the decoder (only 60 bits are needed). The high nibble of the first 74h byte seems to have the value eh or fh in normal encrypted operation and ch or dh in the 'soft scrambled' mode where the decoder can descramble the image even without any card. The following information is valid for the 07 and 09 BSkyB card and need not necessarily be true for future smart cards, because these data bytes don't seem to be interpreted in the decoder and so their meaning can be exchanged. A typical BSkyB 74h packet for the 09 series card looks like this: e843 0a888261 0c 29e403f6 20202020202020202020202020202020 fb54ac02 51 The second byte indicates the current date and counts the months since January 1989. In the 07 card, this month code selects one of several 32-byte secret key tables that are used by the hash function. When the switch from the 07 hash algorithm to the new 09 algorithm happened on 1994-05-18, this value jumped from 40h (1994-05) to 43h (1994-08) which might indicate that the activation of the 09 algorithm was originally planned for August. In the 07 card, this value was only interpreted to find an offset into a table with various 32-byte secret keys. The third byte seems to be a random number. This byte together with the month code is used to generate with a quite simple algorithm four XOR bytes which are necessary to decode the command byte and the card number prefix (described below). If you XOR these four bytes with bytes 8 to 11 and if you the XOR only the first of the four bytes with byte 4, then you have decrypted the card number and the command code. The fourth byte is an encrypted command code. Some decrypted known values are: 0x00 Deactivate whole card (message: 'PLEASE CALL 0506 484777') 0x01 Deactivate Sky Movies (message: 'THIS CHANNEL IS BLOCKED') 0x02 Deactivate Movie Channel 0x03 Deactivate Sky Movies Gold 0x06 Deactivate Sky Sports 0x08 Deactivate TV Asia 0x0c Deactivate Multichannels 0x20 Activate whole card (remove 'PLEASE CALL 0506 484 777') 0x21 Activate Sky Movies (remove 'THIS CHANNEL IS BLOCKED') 0x22 Activate Movie Channel ... 0x2c Activate Multichannels 0x40 Pay-per-view account management command 0x80 \ 0x81 \ perhaps 09 card ECM 0xf0 / commands 0xf1 / Packets with incorrect command bytes and correct signatures can irreversibly kill a card (it doesn't even answer the reset). The fifth and sixth byte seem to be parameters for pay-per-view account management (program number and number of tokens) and don't seem to have a meaning for enabling and disabling commands. The lower 7 bits of the seventh byte contain a channel ID. A card number is represented by a 5 byte card address consisting of a 4 byte prefix and a 1 byte suffix. The five bytes for a card are identical to the first 5 bytes of the 70h answer, only the high nibble of the first address byte seems to have a different purpose (unknown). Up to 16 cards with the same card address prefix can be addressed with one single 32-byte 74h message. The bytes 8-11 might contain the common prefix to the addressed cards and the bytes 12-27 the various suffixes. If there are less than 16 different cards to be addressed, then the same suffix byte is repeated several times in order to fill the space. The 4-byte prefix is encrypted like the command byte by XORing it with the four bytes generated using the bytes 2 and 3. The 4 bytes 28-31 contain the digital signature which is simply an intermediate result of the iterations of the hash algorithm. If the checksum, the digital signature, or some of the values in the first 7 bytes of a 74h command aren't correct, then the 78h answer will only contain 8 00 bytes or in some cases 01 00 00 00 00 00 00 00. The final byte 32 is a simple checksum that makes the sum of all 32 bytes a multiple of 256. The 07 card (and also cards used by Sky New Zealand) have an interesting security hole: The card sends to the decoder as many data bytes as specified in P3. By sending a higher length value in the command header to the card, one can get up to 256 data bytes back which seem to be values from the card's RAM that allow some insight into the internal data structures of the card software. 76h: If the authorize button on the decoder is pressed for a few seconds, then the decoder will send a single 76h message with a 00 data byte to the card. 7ah: This command requests from the card an ASCII text which is then displayed on the TV screen. The display field is 12 characters wide, one or two lines high and no lowercase letters are supported. The lower 5 bits in the first byte indicate, how long the text is which is to be displayed: 0 for no display, 12 for a single line and 24 for 2 lines. The highest 3 bits of the first byte seem to be some kind of display priority. The number there (0-3) must be high enough if standard decoder messages have to be suppressed. The remaining 24 bytes contain the ASCII test. The meaning of the other commands is unknown, some of them are never used currently. Perhaps these commands are used for the Fiat-Shamir identification exchange described in the patent. Some cards understand also additional instruction codes which can't be issued by a normal decoder. E.g. a BSkyB 09 card understands also 12h, 86h, 88h, 8ah and 8ch. These commands are perhaps used in order to test or configurate the card at the factory, etc. Please contact me if you find out anything new. My e-mail address is mskuhn@cip.informatik.uni-erlangen.de. 5 VCL File Format The Videocrypt Card Logfile format (VCL) is used by some peoples for performing the delayed data transfer procedure described in section 2. Person A with a valid card can record the dialog between the decoder and the card for a certain program P and transmit this information as a VCL file to person B who has no card and has recorded with a VCR only the encrypted signal of program P. Person B now connects the Videocrypt decoder between the VCR and the TV set and connects the card slot of the decoder to a PC. Using the information in the VCL file, B's computer can now also decrypt program P. This is of course only possible for the few hours which are covered by the information in the VCL file. Not all of the information exchanged between the card and the decoder is necessary for descrambling the TV signal. The VCL format uses this fact in order to save a lot of storage space. Only 12 bytes of high entropy (that means: almost uncompressable) are stored every 2.5 seconds. So a VCL file of a 1 hour program is only about 17 kbytes large. In addition, VCL files don't contain any information about the card owner (especially not the card serial number), which appears in normal full log files. (The only potential security hole is the remaining nibble in the 78h data, consequently it should be cleared in order to avoid card specific information to leak into the VCL file.) VCL files have a very simple binary format consisting of a 128 byte header and arbitrarily many 12 byte records. At the end, VCL files may be padded with zero bytes to a multiple of the operating system's disk sector size, so that no RAM contents can leak in there out of an unsecure system like MS-DOS. Don't forget to use a binary mode if you transfer VCL files or their contents will be rendered unusable. The 128 byte header has the following format: byte number purpose 0 - 3 ASCII String 'VCL1' which identifies the file type and version of the format. 4 - 7 The number of 12-byte records stored in this file encoded as a bigendian (most significant byte first) 32-bit unsigned integer value. 8 - 23 Date and time when the recording started. Format: yyyymmddThhmmssZ, where yyyymmdd are year, month and day (e.g. '19940618'), hhmmss are hour, minute and second (e.g. '235959'), T ist just the ASCII letter T, and Z is the ASCII letter Z if the time is UTC or a zero byte, if the time is local time. The digits are ASCII characters. 24 - 55 Name of the satellite or cable system from which the recording was done. This is a zero terminated ASCII string with only characters between 20h and 7eh. As many zero bytes are appended as necessary for filling up the 32 bytes. The same format is also used for the next two text fields. Example: 'Astra'. 56 - 63 Name/number of the transponder from which the recording was done. Example: '08' for Sky One on Astra. 64 -127 Description of what has been recorded. Example: 'Star Trek: TNG, episode 123' After the first 128 bytes follow as many 12 byte records as announced in bytes 4-7. Each record represents a 74h/78h Videocrypt protocol pair and constists of two fields: The first 4 bytes are the final 4 bytes of the 74h data part, the remaining 8 bytes are the data part of the corresponding 78h command. Four bytes of each 74h packet are enough to allow a card emulator to quickly and reliably synchronize with the queries of the decoder. The final four bytes of the 74h commands have been selected because of their high entropy (signature and checksum).